エクストリームプログラミング（XP）に少し触れただけの多くの人にとって、XPはソフトウェア設計の死を招くように見える。多くの設計活動が「Big Up Front Design（前もって行う大規模な設計）」として嘲笑されるだけでなく、UML、柔軟なフレームワーク、さらにはパターンなどの設計技法も軽視されるか、完全に無視される。実際、XPは多くの設計を伴うが、確立されたソフトウェアプロセスとは異なる方法で行う。XPは、進化を現実的な設計戦略にすることを可能にするプラクティスによって、進化型設計の概念を活性化させた。また、設計者はシンプルな設計を行う方法、リファクタリングを使用して設計をクリーンに保つ方法、進化型スタイルでパターンを使用する方法を学ぶ必要があるため、新たな課題とスキルを提供する。

継続的インテグレーションは、チームの各メンバーが少なくとも毎日、自分の変更をコードベースにマージし、同僚の変更と統合するソフトウェア開発プラクティスです。これらの統合はそれぞれ、自動ビルド（テストを含む）によって検証され、統合エラーをできるだけ早く検出します。チームは、このアプローチにより、デリバリーの遅延リスクが軽減され、統合の労力が軽減され、新しい機能で迅速に拡張するための健全なコードベースを促進するプラクティスが可能になることを発見しています。

リファクタリングとは、既存のコード本体を再構築し、外部の動作を変更せずに内部構造を変更するための規律ある手法です。その中心となるのは、一連の小さな動作保存変換です。各変換（「リファクタリング」と呼ばれます）はほとんど何も行いませんが、これらの変換のシーケンスは、大幅な再構築を生み出すことができます。各リファクタリングは小さいため、うまくいかない可能性は低くなります。システムは各リファクタリングの後も完全に機能し続けるため、再構築中にシステムが深刻な障害を起こす可能性が低くなります。

今日のソフトウェア開発で働く多くの人々は、ペアプログラミングのプラクティスについて聞いたことがありますが、それでも業界ではまだ部分的にしか採用されていません。その受け入れがまちまちである理由の1つは、その利点がすぐには明らかではなく、中長期的に報われることです。また、「2人が1台のコンピューターで作業する」ほど単純ではないため、多くの人が不快に感じるとすぐに却下してしまいます。しかし、私たちの経験では、ペアプログラミングは、共同作業と高品質のソフトウェアにとって不可欠です。

6月下旬、100人以上の人々が地中海のサルデーニャ島に集まり、XP2000カンファレンスに参加し、エクストリームプログラミング（XP）やその他の柔軟な方法論について議論しました。

2002年5月末、XPコミュニティは再び地中海のサルデーニャ島に集まりました。この記事では、Ken Schwaber、David Parnas、Enrico Zaninotto、Bill Wake、そしてStandish GroupのJim Johnsonによる全体講演を見ていきます。彼らは私を、アジャイル開発の本質、数学的仕様の役割、不可逆性の複雑さ、メタファー、そしてソフトウェアコストを大幅に削減するための最良の方法についての考察へと導いてくれます。

XPの魅力の1つは、XPを実行するために何をすべきかについて、非常に明確な声明を出していることです。さらに、その一連のプラクティスは、互いにうまく適合するように注意深く設計されています。何かを取り除くと、深刻な結果が生じます。しかし、XPやその他のアジャイルメソッドの原則の1つは、それらが自己適応型であるということです。つまり、プロジェクトを開発しているときにプロセスを変更する必要があります。この概念は、XPの厳格なプラクティスとどのように適合するのでしょうか？

2001年にSnowbirdで開催されたマニフェストにつながる会議に行ったとき、ジムは彼が執筆中の本のインタビューをしました。それは、エクストリームプログラミングと、数日後に私たちがアジャイルソフトウェア開発と呼ぶようになったものについての私の考えのスナップショットを提供しています。

私たちの著書Planning Extreme Programming（エクストリームプログラミングの計画）を宣伝するためにピアソンと行われたインタビュー。XPの背景と、XPプロジェクトにおける計画の役割について語り合っています。

ケント・ベックは、1990年代後半にエクストリームプログラミングを開発していたときに、シンプルな設計に関する4つのルールを思いつきました。私はそれらを次のように表現します。

C3は、クライスラーの給与計算プロジェクトであるChrysler Comprehensive Compensationプロジェクトの略称であり、エクストリームプログラミングの「誕生プロジェクト」として有名になりました。

私が遭遇したコードオーナーシップには、さまざまなスキームがあります。私はそれらを3つの大きなカテゴリに分類します

アジャイルメソッドについてよくある誤解があります。これは、ユーザーストーリーが作成され、開発活動を通じてどのように流れるかに焦点を当てています。誤解は、プロダクトオーナー（またはビジネスアナリスト）がユーザーストーリーを作成し、開発者に実装を依頼するというものです。これは、プロダクトオーナーから開発への流れであり、プロダクトオーナーは*何を*行う必要があるかを決定し、開発者は*どのように*行うかを決定する責任があるとされています。

Daniel Terhorst-Northの最近のソフトウェア職人技に関するブログ記事は、多くのブログでの議論を引き起こしました（興味があれば以下に要約します）。そこには多くのことがありますが、彼のテーマの1つが特に私と共鳴したので、この記事を書きました。

エクストリームプログラミング（XP）は、主にケント・ベックによって開発されたソフトウェア開発方法論です。XPは最初のアジャイルメソッドの1つであり、実際、XPは2000年代初頭にスクラムが支配的になる前は、90年代後半と2000年代初頭に支配的なアジャイルメソッドでした。多くの人々（私自身も含む）は、XPがアジャイルメソッドに注目を集めた主要な触媒であり、アジャイル開発を始めるための基盤としてスクラムよりも優れていると考えています。

オンサイト顧客は、ホワイトブックに記載されている12のプラクティスの1つである、エクストリームプログラミングのプラクティスの1つです。顧客は、質問に答え、開発チームと対話するために、オープンな作業エリアで開発者と一緒に座る必要があると述べています。実際、彼らは開発チームの一員であり、チームの成功は開発者と同じくらい彼らにかかっていることを認識しています。彼らはこれを行うために通常の仕事を諦める必要はありませんが、物理的に存在している必要があります。

ペアプログラミングは、開発者が2人1組で作業するソフトウェア開発プラクティスです。すべての重要なコードは、通常は1台のモニター、多くの場合は1台のキーボードを使用して、並んで座っている2人のプログラマーによって記述されます。コードを追加する際に、各ステップについて一緒に話し合います。

ペアプログラミングに関するよくある誤解のいくつか。

XP愛好家なら誰でも4つの価値と12のプラクティスについて知っていますが、15の原則について知っている人はどれくらいいるでしょうか？先週JAOOでKentがそれらについて話したとき、私は知らなかったことを告白します。講演の後、私はKentにそれらについて尋ねました。「それらは白本に載っていましたか？」と。「はい」と彼は答えました。「『基本原則』という章に巧妙に隠されています」。

自己テストコードとは、私がリファクタリングの中で、機能的なソフトウェアと併せて包括的な自動テストを書くプラクティスを指すために使用した名前です。うまくいけば、テストを実行する単一のコマンドを呼び出すことができ、これらのテストがコードに潜むバグを明らかにすると確信できます。

ユニットテストはソフトウェア開発でよく話題になり、私がプログラムを書き始めてからずっと馴染みのある用語です。しかし、ほとんどのソフトウェア開発用語と同様に、それは非常に曖昧に定義されており、人々が実際よりも厳密に定義されていると考えるときに混乱が生じることがよくあります。

人々がエクストリームプログラミングについて話すとき、彼らはしばしば適応的な計画スタイルや進化的な設計アプローチなどに焦点を当てます。私が特に興味を持っているのは、小規模ながらも増加しつつある傾向、つまり、非常に低い欠陥率（1か月あたり1つ未満の運用バグ）を持つXPプロジェクトの数が小規模ながらも増加していることです。

ベロシティとは、作業量の概括的な記述を経過時間と結びつけることで計画を調整するのに役立つ概念です。ベロシティとは、チーム（または個人の場合は個人ベロシティ）が一定期間にどれだけの作業を完了したかを示すものです。昨日の天気の原則に従い、通常は過去の期間に完了した作業量を測定することでベロシティを決定する必要があります。一般的なアプローチは、過去3期間のベロシティを平均して、将来の期間のベロシティを決定することです。ベロシティはもともとエクストリームプログラミングの一部として形成されましたが、その後普及し、今ではあらゆる種類のアジャイルソフトウェア開発で広く使用されています。

これは、今日完了する作業量は昨日と同じくらいになるという原則です。反復型プロジェクトでは、今回のイテレーションでは前回のイテレーションと同じくらいの作業を行うように計画するべきだと言っています。この用語はエクストリームプログラミングコミュニティに由来します。